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Abstract 


This document adds a small number of mandatory tests required for the 
secure operation of the Internet Key Exchange Protocol version 2 
(IKEv2) with elliptic curve groups. No change is required to IKE 
implementations that use modular exponential groups, other than a few 
rarely used so-called Digital Signature Algorithm (DSA) groups. This 
document updates the IKEv2 protocol, RFC 5996. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6989. 


Copyright Notice 


Copyright (c) 2013 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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1. Introduction 


IKEv2 [RFC5996] consists of the establishment of a shared secret 
using the Diffie-Hellman (DH) protocol, followed by authentication of 
the two peers. Existing implementations typically use modular 
exponential (MODP) DH groups, such as those defined in [RFC3526]. 


IKEv2 does not require that any tests be performed by a peer 
receiving a public Diffie-Hellman key from the other peer. This is 
fine for the common case of MODP groups. For other DH groups, when 
peers reuse DH values across multiple IKE sessions, the lack of tests 
by the recipient results in a potential vulnerability (see 

Section 4.1 for more details). In particular, this is true for 
Elliptic Curve (EC) groups, whose use is becoming ever more popular. 
This document defines such tests for several types of DH groups. 


In addition, this document describes another potential attack related 
to the reuse of DH keys: a timing attack. This additional material 
is taken from [RFC2412]. 


This document updates [RFC5996] by adding security requirements that 
apply to many of the protocol’s implementations. 
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1.1. Conventions Used in This Document 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


2. Group Membership Tests 


This section describes the tests that need to be performed by IKE 
peers receiving a Key Exchange (KE) payload. The tests are 
RECOMMENDED for all implementations but only REQUIRED for those that 
reuse DH private keys (as defined in [RFC5996], Section 2.12). The 
tests apply to the recipient of a KE payload and describe how it 
should check the received payload. They are listed here according to 
the DH group being used. 


2.1. Sophie Germain Prime MODP Groups 


These are currently the most commonly used groups; all these groups 
have the property that (p-1)/2 is also prime; this section applies to 
any such MODP group. Each recipient MUST verify that the peer’s 
public value r is in the legal range (1 < r < p-1). According to 
[Menezes], Section 2.2, even with this check there remains the 
possibility of leaking a single bit of the secret exponent when DH 
keys are reused; this amount of leakage is insignificant. 


See Section 5 for the specific groups covered by this section. 
2.2. MODP Groups with Small Subgroups 


[RFC5114] defines modular exponential groups with small subgroups; 
these are modular exponential groups with comparatively small 
subgroups, and all have (p-1)/2 composite. Section 2.1 of [Menezes] 
describes some informational leakage from a small-subgroup attack on 
these groups if the DH private value is reused. 


This leakage can be prevented if the recipient performs a test on the 
peer’s public value; however, this test is expensive (approximately 
as expensive as what reusing DH private values saves). In addition, 
the NIST standard ([NIST-800-56A], Section 5.6.2.4) requires that 
test; hence, anyone needing to conform to that standard will need to 
implement the test anyway. 
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Because of the above, the IKE implementation MUST choose between one 
of the following two options: 


o It MUST check both that the peer’s public value is in range (1 < r 
< p-1) and that r*q = 1 mod p (where q is the size of the 
subgroup, as listed in the RFC defining the group). DH private 
values MAY then be reused. This option is appropriate if 
conformance to [NIST-800-56A] is required. 


o It MUST NOT reuse DH private values (that is, the DH private value 
for each DH exchange MUST be generated from a fresh output of a 
cryptographically secure random number generator), and it MUST 
check that the peer’s public value is in range (1 < r < p-l). 

This option is more appropriate if conformance to [NIST-800-56A] 
is not required. 


See Section 5 for the specific groups covered by this section. 
2.3. Elliptic Curve Groups 


IKEv2 can be used with elliptic curve groups defined over a field 

GF (p) [RFC5903] [RFC5114]. According to [Menezes], Section 2.3, 
there is some informational leakage possible. A receiving peer MUST 
check that its peer’s public value is valid; that is, the x and y 
parameters from the peer’s public value satisfy the curve equation, 
y*2 = x*3 + ax + b mod p (where for groups 19, 20, and 21, a=-3 (mod 
p), and all other values of a, b, and p for the group are listed in 
the RFC defining the group). 


We note that an additional check to ensure that the public value is 
not the point at infinity is not needed, because IKE (see Section 7 
of [RFC5903]) does not allow for encoding this value. 


See Section 5 for the specific groups covered by this section. 
2.4. Transition 


Existing implementations of IKEv2 with Elliptic Curve Diffie-Hellman 
(ECDH) groups may be modified to include the tests described in the 
current document, even if they do not reuse DH keys. The tests can 
be considered as sanity checks and will prevent the code having to 
handle inputs that it may not have been designed to handle. 


ECDH implementations that do reuse DH keys MUST be enhanced to 
include the above tests. 
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2.5. Protocol Behavior 


The recipient of a DH public key that fails one of the above tests 
must assume that the sender is either truly malicious or has a bug in 
its implementation. The behavior defined below attempts to balance 
resistance to attackers that are trying to disrupt the IKE exchange, 
against the need to help a badly implemented peer by providing useful 
error indications. 


If this error happens during the IKE_SA_INIT exchange, then the 
recipient MUST drop the message that contains an invalid KE payload 
and MUST NOT use that message when creating the IKE security 
association (SA). 


If the implementation employs the DoS-resistant behavior proposed in 
Section 2.4 of [RFC5996], it may simply ignore the erroneous request 
or response message, and continue waiting for a later message 
containing a legitimate KE payload. 


If DoS-resistant behavior is not implemented and the invalid KE 
payload was in the IKE_SA_INIT request, the implementation MAY send 
an INVALID_SYNTAX error notification back and remove the in-progress 
IKE SA; if the invalid KE payload was in the IKE_SA_INIT response, 
then the implementation MAY simply delete the half-created IKE SA and 
re-initiate the exchange. 


If the invalid KE payload is received during the CREATE_CHILD_SA 
exchange (or any other exchange after the IKE SA has been 
established) and the invalid KE payload is in the request message, 
the Responder MUST reply with an INVALID_SYNTAX error notification 
and drop the IKE SA. If the invalid KE payload is in a response, the 
Initiator getting this reply MUST immediately delete the IKE SA by 
sending an IKE SA Delete notification as a new exchange. In this 
case, the sender evidently has an implementation bug, and dropping 
the IKE SA makes it easier to detect. 


3. Side-Channel Attacks 


In addition to the small-subgroup attack, there is also a potential 
timing attack on IKE peers when they are reusing Diffie-Hellman 
secret values. This is a side-channel attack, which means that it 
may or may not be a vulnerability in certain cases, depending on 
implementation details and the threat model. 
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The remainder of this section is quoted from [RFC2412], Section 5, 
with a few minor clarifications. This attack still applies to IKEv2 
implementations, and both to MODP groups and ECDH groups. We also 
note that more efficient countermeasures are available for EC groups 
represented in projective form, but these are outside the scope of 
the current document. 


Timing attacks that are capable of recovering the exponent value used 
in Diffie-Hellman calculations have been described by Paul Kocher 
[Kocher]. In order to nullify the attack, implementors must take 
pains to obscure the sequence of operations involved in carrying out 
modular exponentiations. 


One potential method to foil these timing attacks is to use a 
"blinding factor". In this method, a group element, r, is chosen at 
random, and its multiplicative inverse modulo p is computed, which 
we'll call r_inv. r_inv can be computed by the Extended Euclidean 
Method, using r and p as inputs. When an exponent x is chosen, the 
value r_inv’x is also calculated. Then, when calculating (g^y)^x, 
the implementation will calculate this sequence: 


A T 
B=A (r*g^y)^x = (r^x) (g* (xy) ) 

C B*r_inv^x = (r%*x) (r%* (-1*x)) (g* (xy)) = g^(xy) 

The blinding factor is only necessary if the exponent x is used more 
than 100 times. 


4. Security Considerations 


This entire document is concerned with the IKEv2 security protocol 
and the need to harden it in some cases. 


4.1. DH Key Reuse and Multiple Peers 


This section describes one variant of the attack prevented by the 
tests defined above. 


Suppose that IKE peer Alice maintains IKE security associations with 
peers Bob and Eve. Alice uses the same secret ECDH key for both SAs, 
which is allowed with some restrictions. If Alice does not implement 
these tests, Eve will be able to send a malformed public key, which 
would allow her to efficiently determine Alice’s private key (as 
described in Section 2 of [Menezes]). Since the key is shared, Eve 
will be able to obtain Alice’s shared IKE SA key with Bob. 
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4.2. DH Key Reuse: Variants 


Private DH keys can be reused in different ways, with subtly 
different security implications. For example: 


1. DH keys are reused for multiple connections (IKE SAs) to the same 
peer and for connections to different peers. 


2. DH keys are reused for multiple connections to the same peer 
(e.g., when the peer is identified by its IP address) but not for 
different peers. 


3. DH keys are reused only when they had not been used to complete 
an exchange, e.g., when the peer replies with an 
INVALID_KE_ PAYLOAD notification. 


Both the small-subgroup attack and the timing attack described in 
this document apply at least to options #1 and #2. 


4.3. Groups Not Covered by This RFC 


There are a number of group types that are not specifically addressed 
by this RFC. A document that defines such a group MUST describe the 
tests required by that group. 


One specific type of group would be an even-characteristic elliptic 
curve group. Now, these curves have cofactors greater than 1; this 
leads to a possibility of some information leakage. There are 
several ways to address this information leakage, such as performing 
a test analogous to the test in Section 2.2 or adjusting the ECDH 
operation to avoid this leakage (such as Elliptic Curve Cryptography 
Cofactor Diffie-Hellman (ECC CDH), where the shared secret really is 
hxyG). Because the appropriate test depends on how the group is 
defined, we cannot document it in advance. 


4.4. Behavior upon Test Failure 


The behavior recommended in Section 2.5 is in line with generic error 
treatment during the IKE_SA_INIT exchange, per Section 2.21.1 of 
[RFC5996]. The sender is not required to send back an error 
notification, and the recipient cannot depend on this notification 
because it is unauthenticated and may in fact have been sent by an 
attacker trying to launch a DoS attack on the connection. Thus, the 
notification is only useful to debug implementation errors. 
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On the other hand, the error notification is secure in the sense that 
no secret information is leaked. All IKEv2 Diffie-Hellman groups are 
publicly known, and none of the tests defined here depend on any 
private key. In fact, the tests can all be performed by an 
eavesdropper. 


The situation when the failure occurs in the CREATE_CHILD_SA exchange 
is different, since everything is protected by an IKE SA. The peers 
are authenticated, and error notifications can be relied on. See 
Section 2.21.3 of [RFC5996] for more details on error handling in 
this case. 


5. IANA Considerations 
IANA has added a column named "Recipient Tests" to the Transform 
Type 4 - Diffie-Hellman Group Transform IDs registry for IKEv2 
[IANA-IKEv2-Registry]. 


This column has been initially populated as follows. 


4------------------------------------ 4----------------------- + 
| Number | Recipient Tests | 
4------------------------------------ 4----------------------- + 
| 1, 2, 5, 14, 15, 16, 17, 18 | RFC 6989, Section 2.1 | 
| 22, 23, 24 | RFC 6989, Section 2.2 | 
| 19, 20, 21, 25, 26, 27, 28, 29, 30 | RFC 6989, Section 2.3 | 
4------------------------------------ 4+----------------------- + 


Groups 27-30 are defined in [RFC6954]. 


Future documents that define new DH groups for IKEv2 are REQUIRED to 
provide this information for each new group, possibly by referring to 
the current document. 
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